Many integrated circuits are comprised of register sets and integrated functionality. For example, hardware device add-ons in the personal computer (PC) system environment, such as graphic accelerator chips, contain integrated functionality that are accessed through register sets. A particular function in a hardware application specific integrated circuit (ASIC) is activated by accessing the correct associated register. The hardware defines its register space within the PC environment that maps its internal functions through an external host bus interface. The exact placement of the registers is determined by the space requirements of the ASIC added to the PC system.
The registers themselves provide views or windows to internal hardware storage elements, typically flip-flops (flops) or latches, which are referred to herein as "fields". The grouping of the various fields form registers (up to 32-bits in length in conventional PC architecture). By reading or writing to the registers, the internal fields are externally accessed and programmed. The action of accessing these fields causes the hardware to be set in a particular manner and ultimately to perform the desired associated function. Since the grouping of these fields can be arbitrary, for programmer convenience sake, fields associated with similar functionality and meaning are typically grouped together into common register views. This occurs as part of defining the register specification for a particular hardware device. Often, the same fields are mapped or aliased into various registers in order to provide a more flexible programming model. In this scenario, multiple methods are provided to access a single field within the ASIC. Thus, the registers that are formed contain one or more fields (typically, an array of associated fields) that can be read or written to in order to program the hardware device to perform some functionality.
Some fields are passive while others are active. The passive fields simply act as storage to keep track of user defined parameters (such as the length of a line to draw, in the case of a graphics accelerator). Other active fields are intended for initiating an action (such as actually drawing a line). The action that is initiated uses the data and parameters set in the passive, storage fields to define the exact behavior of the action. In this example, the line that is drawn will be as long as the length specified in the designated "length" field (other parameters, such as direction, color and slope also influence the line drawing action).
In the development process, the behavior of new hardware devices is typically first defined. This is usually followed by defining the registers for the device that provide access to the hardware's internal functionality. The design of the hardware devices is typically a long, arduous task that requires exact attention to detail on all levels in the design. At the most fundamental level, the design has to meet to functional specifications. Before any design can be manufactured, it must be verified that it satisfies all specifications. The verification is typically realized through extensive computer simulation and comparison with a reference set of results, referred to herein as a `regression suite` of tests. In the course of generating this regression suite, it may be necessary to build a software behavioral model of the device being tested.
This behavioral model mimics the behavior of the device under design down to the functional level. The behavioral model must precisely resemble the device from the external host's (such as a CPU) point of view. It is this requirement that forces the software behavioral model to adhere to the register specification associated with the device. Since a device may consist of hundreds of registers, each potentially with multiple fields, the development and maintenance of the software behavioral model and hardware device is complicated, time consuming, and often inefficient. Therefore, there exists a need for automating and simplifying the process of developing a suitable software behavioral model.
In conventional ASIC hardware design processes the different hardware device design phases can be characterized as follows: (1) an initial device concept phase consisting of defining the product purpose, scope, and usefulness; (2) a device definition phase; and (3) a design implementation phase.
The device definition stage contains two branches which, for the most part, execute in parallel with strong interaction to the initial design concept phase. The two branches are typically architectural and algorithmic selection and programming of the behavioral model. The architectural and algorithmic selection is generally accomplished through formal methods and/or by functional modeling (behavioral modeling) and computer based hardware simulation of the device. The programming of the behavioral model entails specifying the host register interface (i.e., register specification) that meets two conditions: (i) all of the required functionality of the device is accessible through the registers, and (ii) the register layout provides a convenient method for software developers for accessing the inherent functionality in the device. The development of the programming model is often an iterative stage since its usefulness and effectiveness cannot be fully determined until software is actually written to exercise the programming model.
The design implementation stage involves implementing the actual design as specified, typically using a Hardware Description Language, such as VHDL or VERILOG to simulate operation of the hardware design. The design implementation phase often involves many iterations and modifications to both the functionality and register specification of the device. This is strongly dictated by the technology, resources, and schedule for completing the design. As a result, the software behavioral model constantly undergoes often drastic changes in an effort to keep pace and maintain consistency with the ever changing hardware design.
In conventional development processes, the different phases of design are often decoupled and assume the design implementation phase will exactly follow the specification. The software behavioral model is typically written and updated manually according to the initial specification, thought to be static. However, due to the iterative nature of design, the software model required extensive changes, particularly at the register interface level, in order to satisfy the new design requirements. This generally involves excessive overhead and unnecessary work and often quickly lead to an inconsistent model at the detailed register level. Therefore, there exists a need for an ASIC design system in which the process of software behavioral model development is mapped into all the stages of design in an automated manner in order to efficiently and consistently produce a software modeling interface that precisely reflects the state of the device under design.